Not that it changes much about the proposal at hand, but "make invalid states unrepresentable" is not achieved if I can do

myFancyPlatform := Platform{
    KubernetesDistribution: RKE2,
    Hypervisor: CloudHypervisor,
    HardwarePlatform: Unknown,
}

Under the assumption of only validating constructors being used in the program, of course. I do acknowledge that my example is counter-intuitive for that, but it's a simplification, after all.

Additional fields that come to mind: Snapshotter, ImageVariant.

Can you elaborate on ImageVariant?

with GPU support or without, debug or prod, ...

I think those should be additional fields, ultimately. That's the key point I want to convey in this proposal. It seems I need to make that more clear?

How do Platforms relate to runtimes? A runtime could be used with more than one image (not easily, but possible), but not with more than one hypervisor or snapshotter.

Runtimes in the sense of Kata runtimes?

Kubernetes runtimes.

The node-installer could figure out a lot of configuration without user interaction - TEE flavour, containerd paths, maybe even hypervisor. On the other hand, outside the runtime the config is only used to decide which genpolicy to use and to populate reference values. I wonder whether we actually need to expose the entire runtime config to the user.

I think large parts of it have to be exposed. It might be possible that you have an instance that has GPUs available but don't want to run GPU-enabled Contrast on it, for example.

Also, reference value generation needs almost all values, if I'm not mistaken?

You picked the one dimension that I did not list as candidate for automation ;)

It's still an interesting question whether / how we want to deal with mixed images. As a user, how do I tell Contrast to use a GPU image for pod A, but a plain image for pod B? I imagine a config file is not granular enough here. If there is only one image per runtime, how do I mix two runtimes with one coordinator? (I think that's a scenario we might want to support eventually, though)

The reference values need the image measurements, the genpolicy choice and the hardware reference values, where the last two are only a question of AKS-CLH vs. rest.

The reference values need the image measurements, the genpolicy choice and the hardware reference values, where the last two are only a question of AKS-CLH vs. rest.

For hardware reference values, I think it's also a matter of TDX vs. SNP (Genoa) vs. SNP (Milan) and so on, right?

About mixed images, how the customer decides to do that is TBD still, I think. I don't have the solution at hand for this.

About "one image per runtime": I think we could ship all variants in the node-installer if we can make them reasonably small?

We don't fill hardware values for bare metal, so it's just image measurements I think.